Closed Bug 163503 Opened 22 years ago Closed 18 years ago

[gtk1] Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: georgi, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files)

Testcase showning the bug
2.54 KB, text/html
Details
Same behavior, but in a table
813 bytes, text/html
Details
Testcase from bug 275069
507 bytes, text/html
Details
A simple testcase that only uses :focus and requires three clicks to show the list.
522 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020819
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020819

If on select form element are applied :hover and :focus pseudo class,
the drop down star acting not like standart dropdowns.

Reproducible: Always

Steps to Reproduce:
1. View the attached testcase

    
    

    
  
Confirming.  John do you know anything about this?
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Sounds a bit like bug 154670, but not the same.

    
    

    
  
all three testcases regressed at the same time (2002051621 - 2002051721, same as
bug 154670).  the third testcase is (almost) bug 154670.

    
    

    
  
-->
Assignee: rods → jkeiser

    
    

    
  
*** Bug 165376 has been marked as a duplicate of this bug. ***
Blocks: 172111

    
  
No longer blocks: 172111
Depends on: 154670

    
    

    
  
*** Bug 173056 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 174982 has been marked as a duplicate of this bug. ***

    
    

    
  
Here's what I see:
- If a dropdown is already open, it takes 2 clicks to open another dropdown
- If no dropdowns are open, it only takes 1 click
This part of the bug is realated to bug 66834.

For me, where :hover or :focus is on the select doesn't affect the behavior, so
I guess I'm not seeing this bug.

    
    

    
  
The example in http://www-xray.ast.cam.ac.uk/~jss/test-option.html shows the bug
well. The drop down box never opens unless you double click, and it doesn't open
reliably then (example from bug 173056). This is with Mozilla 1.2b (2002101612)
on Linux.



    
    

    
  
Jeremy, I only need 1 click to drop the box down in that example, at least in
win2k. Maybe it's a platform thing. I'm on the tip from last Wednesday October
16, 2002.

    
    

    
  
The bug is only seen in linux builds, that's why OS is set to Linux only


    
    

    
  
I don't know what the difference is between this bug and bug 154670.  That bug
was caused by bug 126480 (hewitt)

    
    

    
  
Someone mentioned problems with :active as well (on mozilla-style).

    
    

    
  
*** Bug 177918 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 180900 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 181005 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.3beta

    
    

    
  
Reproduced in 12/23 Linux Trunk build.
Keywords: testcase

    
    

    
  
*** Bug 186404 has been marked as a duplicate of this bug. ***
Summary: Using :hover and (or) :focus on select fields makes them almost unusable → Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable

    
    

    
  
*** Bug 192066 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 195123 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 196208 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 211093 has been marked as a duplicate of this bug. ***

    
    

    
  


  
I found that this behavior is still present if the select is inside a table tr
that has a :hover style (I would guess that the :focus styles would behave
similarly as well), instead of the style being on the select element itself. 
See the testcase.

    
    

    
  
*** Bug 224114 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 228054 has been marked as a duplicate of this bug. ***

    
    

    
  
The sample URL in dup bug 228054 shows that this doesn't need a table to occur.

URL: http://www.dmbr.ugent.be/~didier/moz16-hover_select_inoperable.html
Keywords: regression

    
    

    
  
In dup bug #228054, I reported that 1.4 worked perfectly OK ; reading this bug
#163503, I should have added I only considered the Red Hat RPM builds (RHL9 1.3
and Fedora Core 1 1.4.1). I just tested all mozilla.org builds since 1.4 (both
with and without gtk/xft), and they all show the same erroneous behaviour.

Tonight, I'll compile the source tarball with the FC1 1.4.1 buildconfig
parameters. If that does not provide a clue, I suppose the patches provided in
the RedHat SRPMs will provide a clue.



    
    

    
  
WRT comment #29 :

I recompiled the mozilla-source-1.6b.tar.bz2 (20031209) source tarball with the
RedHat/Fedora buildconfig parameters :
"--prefix=/usr --libdir=/usr/lib --enable-optimize=-O2 --disable-debug
--enable-pie --with-default-mozilla-five-home=/usr/lib/mozilla-1.4.1
--disable-strip-libs --disable-tests --enable-xinerama --enable-nspr-autoconf
--enable-extensions=default,irc --without-mng --enable-crypto --disable-xprint
--without-system-nspr --with-system-zlib --enable-default-toolkit=gtk2
--disable-freetype2 --enable-xft --mandir=/usr/share/man"

This fixes the issue.


IMHO, it could prove advantageous to compare mozilla.org's buildconfigs with
this one, as they all (both xft and non-xft) lead to the erroneous behaviour,
just like the one below (which I previously used) :

"--enable-calendar --with-system-zlib --enable-xft --enable-crypto
--enable-extensions=default,inspector,-irc --enable-xpctools --disable-tests
--disable-logging --enable-reorder --enable-strip --disable-debug
--enable-optimize=" -O2 -march=pentium3 -pipe" --enable-toolkit=gtk2
--enable-striplibs "

    
    

    
  
*** Bug 229886 has been marked as a duplicate of this bug. ***
Blocks: 232514

    
    

    
  
I was recently hit by this bug in the "<select> inside a <tr> with a :hover"
case. I confirm that this bug is still present with the following releases: 
 * Mozilla 1.6 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
 * Firefox 0.8 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207
Firefox/0.8

I also tested with these nightly and the bug is still present:
 * Mozilla 1.7b - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040324
 * Firefox 0.8+ - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b)
Gecko/20040324 Firefox/0.8.0+

I run under an old Mandrake Linux 8.1 (Glibc-2.2.4, XFree86-4.1.0), but this
also occurs with Firefox 0.8 under a recent Mandrake (where XFree86 is 4.3 I
think). 

    
    

    
  
Bug 239084 looks like a dupe of this. I attached a testcase over there, I can
put it in here (or just look at that one).

I *only* see it in gtk1 builds. Using a gtk2 build, the problem is not
reproducable. Both testcases on this bug work right using Mozilla/5.0 (X11; U;
Linux i686; en-US; rv:1.7b) Gecko/20040410 Firefox/0.8.0+ (which is in fact a
gtk2 build).

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040411 (gtk1) *does*
show the symptoms in both testcases. Mine is reduced pretty far, it uses
{text-decoration: underline} on a form element and gets the same behavior.

    
    

    
  
So.... if I change the restyle hint for background and color changes from
NS_STYLE_HINT_VISUAL to nsChangeHint_RepaintFrame the problem in the first
testcase disappears.

That's not a fix, of course (though I think we should go through and do it as
possible, since view sync ain't cheap), since other style changes _do_ require
the view sync.  But apparently something
nsContainerFrame::SyncFrameViewProperties does just messes with the popup's
little mind.  This is born out by comment 33 -- apparently something in the gtk1
widget impl is just unhappy about SyncFrameViewProperties and tears down the
popup....

    
    

    
  
*** Bug 239084 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 256477 has been marked as a duplicate of this bug. ***

    
    

    
  
this bug in mozilla 1.7.3 still persists...

    
    

    
  
Yes, we know.

Reassigning this to GFX widgetry, per comments....
Assignee: john → blizzard
Status: ASSIGNED → NEW
Component: Layout: Form Controls → GFX: Gtk
Keywords: helpwanted
Priority: P2 → --
QA Contact: tpreston → ian
Target Milestone: mozilla1.3beta → ---

    
    

    
  
*** Bug 258724 has been marked as a duplicate of this bug. ***

    
    

    
  
OK, resending my experience with that bug, since I filed it to a duplicate bug.
I'm using Select inside of a table, which is using hover:

Built firefox under Linux from source both gtk and gtk2.
gtk2 build - no problem at all
gtk build -the described behavior from previous posts

removing the hover from the stylesheet makes the select response as usual.

I'm using gtk 1.2.7 - quite old, I know. Don't know if this is gtk or firefox
related. I'd prefer firefox ;-) , don't wan't to upgrade gtk on all my machines,
and as the selection works without the hover, the error is likely to be in firefox.


    
    

    
  
the source was (of course) firefox-1.0, forgot to mention ...

    
    

    
  
*** Bug 275069 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 232514 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 277471 has been marked as a duplicate of this bug. ***

    
    

    
  
I have reproduced slightly alternate behaviour related to this bug which may
help under the Solaris builds of Moz and FF.  If I set a style change for
background-color on the :focus pseudo-event to a single-line select box then
when the box is focussed the style change is correctly implemented.  If the
focus change was achieved via any other means than by mouse-click, then all
remains well.  However, if focus was by mouse-click, the expected behaviour of
opening the list does not occur *visibly*.  However, the control acts as if this
has occurred, requiring a further two clicks or close-open keystrokes to
invisibly close and finally visibly open the select pane.

    
    

    
  
*** Bug 294390 has been marked as a duplicate of this bug. ***

    
    

    
  
Quite a few comments suggest it doesn't occur with GTK2. However I can confirm
with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421
Firefox/1.0.3 (Debian package 1.0.3-2), that's a GTK2 build. I don't think it
matters what the parent tag is either, I can reproduce with a <div> container
(http://jon.dowland.name/code/bugs/select-parent-hover.html)

    
    

    
  
> matters what the parent tag is either, I can reproduce with a <div> container
> (http://jon.dowland.name/code/bugs/select-parent-hover.html)

that's a completely different bug because the :hover applies to the div and not
the form control itself.  And the <div> /is/ required (it would be a very boring
testcase without it).

    
    

    
  
(In reply to comment #48)
> Quite a few comments suggest it doesn't occur with GTK2.

I'll try to clarify this.  It seems there are three issues mentioned in this
single bugzilla entry:  1. the original bug, 2. the one from comment #25, and 3.
the one from comment #48.


1. The original bug (SELECT with :hover, :focus) occurs in Gtk2 (see the version
details below), though not exactly as described in attachment (id=95883):  The
first SELECT (plain) in that attachment pops-up correctly, the second one
(:focus) needs three clicks to pop up, the third one (:focus, :hover) behaves
correctly, the fourth one (:focus, :hover, :focus:hover) needs three clicks. 
Interestingly, once tripple-clicked, the second and fourth SELECTs behave
correctly until you reload the page.  There is a tiny issue with :hover already
covered in (now orphaned) Bug 37495.

2. The bug described in comment #25 (i.e., plain SELECT in TABLE/TR/TD with
:hover; also refered to in comment #32) does not occur in current Gtk2 (as noted
in comment #40).  The SELECT works fine in the attachment (id=130550), even with
:hover on TD, or with the TABLE removed completely and SELECT placed in a DIV
with :hover.  The tiny issue mentioned above applies here as well.

3. The bug from comment #48:

> However I can confirm
> with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421
> Firefox/1.0.3 (Debian package 1.0.3-2), that's a GTK2 build. I don't think it
> matters what the parent tag is either, I can reproduce with a <div> container
> (http://jon.dowland.name/code/bugs/select-parent-hover.html)

It really does not matter what the parent element is.  But it does matter what
you do with the parent on hover.  If you just change the background color (as in
attachment (id=130550)) or change/add a border, the select inside behaves
correctly.  On the other hand, if you show the otherwise hidden select
(http://jon.dowland.name/code/bugs/select-parent-hover.html), the select needs
two (not three as in the original bug!) clicks to pop up its menu. Once
double-clicked, the select works fine until it is hidden again.


To sum up:  Comment #25 looks as a Gtk1 or old Gtk2 problem, and is gone now. 
In the original bug, and the one from comment #48, different number of clicks
are needed to pop up the select.  This provides some evidence to the claim from
comment #49, that these issues are not related.


Versions:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4
(Debian package 1.0.4-2)
ii  libgtk2.0-0    2.6.8-1        The GTK+ graphical user interface library
ii  libc6          2.3.2.ds1-22   GNU C Library: Shared libraries and Timezone

    
    

    
  
I've found a little workaround for the original problem (three clicks select item with :focus and :hover under linux), it's only works, when the :focus is the first definition in ths CSS section:

errorneous:

    SELECT:hover { background-color: #A0C0F0; }
    SELECT:focus { background-color: #F0F0F0; } 

correct:

    SELECT:focus { background-color: #F0F0F0; } 
    SELECT:hover { background-color: #A0C0F0; }


I hope, this helps in fixing the bug. :)


    
    

    
  


  
I've attached a simple testcase that only uses :focus. It requires three clicks on the down arrow to show the drop-down.

Tested in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051210 SeaMonkey/1.5a" and "Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.8) Gecko/20051111 Firefox/1.5". These are GTK2 builds.

    
    

    
  
*** Bug 250810 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 320849 has been marked as a duplicate of this bug. ***

    
  
Depends on: 281551

    
    

    
  
could you please stop to search for work-arounds and keep telling me, that even with your buggy software i don't need more than three clicks to open the select. 
the standard says, that the select box is open after the first click, whatever the CSS may be.
please correct the bug.
suomi

    
    

    
  
For what it's worth, Mac Firefox 1.0.2 does not display this problem.  So it seems to be Linux only.


    
    

    
  
Fixed by the checkin for bug 281551.
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: helpwanted
Resolution: --- → FIXED

    
    

    
  
You sure?  That patch is GTK2-only, and this bug was present with both GTK1 and GTK2.  Did you actually test both?

    
    

    
  
Reopening pending a fix for gtk1.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  
Assignee: blizzard → nobody
Status: REOPENED → NEW
QA Contact: ian → gtk
Summary: Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable → [gtk1] Using :hover and (or) :focus and (or) :active on select fields makes them almost unusable

    
    

    
  
*** Bug 352481 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 354482 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 348430 has been marked as a duplicate of this bug. ***

    
    

    
  
Given that GTK1 support is being dropped....
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WONTFIX

    
    

    
  
Except it also happens with GTK2
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

    
    

    
  
Actually no.  It doesn't.  See comment 57.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: